The present invention generally relates to a virtual machine (i.e., software implementation of a computing device that runs programs like a real computing device). More particularly, the present invention relates to allowing a guest operating system (i.e., an operating system of a virtual machine) to modify an entry of TLB (Translation Lookahead Buffer) (i.e., a cache memory that is used by a memory management hardware to improve a speed of virtual address translation; virtual address translation means a mapping from a virtual address to a physical address) directly without an involvement of a hypervisor (i.e., a virtualization (i.e., separating an operating system from an underlying hardware resources) platform that allows multiple operating systems to run on a host computer at same time).
To enable a secure running of an application, operating systems provide an isolated address space (i.e., a range of discrete addresses solely assigned to an application) to each application. The operating system (OS) actively manages its physical memory (i.e., an actual memory such as DRAM, SRAM and SDRAM) in chunks, commonly referred to as pages. The physical memory is represented as physical addresses (PAs; actual addresses in DRAM, SRAM and SDRAM). A virtual memory refers to a technique which gives an application an impression that the application has contiguous address space, while in fact the address space may be physically fragmented and may even overflow to a disk storage. A virtual memory address may correspond to a physical memory address, as illustrated in FIG. 1(a).
FIG. 1(a) illustrates a virtual address space 10, which is managed by an application, that is divided into three partitions such as text, data and stack. The text partition is usually used for storing program codes. The data partition is usually used for storing data needed for running the program codes. The stack partition is usually for storing temporary data in case of function calls. The physical address space 12 is actual address space that is assigned to the application. FIG. 1(a) illustrates a virtual address is mapped to a physical address (a virtual address corresponds to a physical address). For example, a virtual address 0x00010000 is mapped to a physical memory address (14). A stack pointer that points to a top of the stack is actually mapped to a physical memory (16). In the physical address space (12), an entry such as a physical address (18) is not assigned to any process, while an entry such as a physical address (14) is assigned to a process in the application.
An OS maintains address translations (e.g., mapping a virtual address to a physical address) for an address space of an application. The OS implements these translations per an address space in a hierarchical structure depicted in FIG. 1(b). The structure implementing the translations is called page tables (i.e., a data structure used by a virtual memory in an OS to store mappings between virtual addresses and physical addresses). The page tables can also be implemented by hash tables. Page tables are generally managed by an OS. An application cannot access the page tables and does not know existence of the page tables.
FIG. 1(b) illustrates a virtual address 30 includes a first offset 20, a second offset 21, a third offset 22 and a page offset 23. The first offset 20 is used to index an entry 24 in a first level page table 25. The entry 24 may point to a second level page table 27. Then, the second offset 21 is used to index an entry 26 in the second level page table 27. The entry 26 may point to a third level page table 28. The third offset 22 is used to index an entry 29 in the third level page table 28. At the entry 29, by using the page offset 23, an address translation (i.e., a mapping from a virtual address to a physical address) is retrieved. The retrieved address translation may also include a page index (“page-idx”) and protection bits (“prot”) (i.e., bits indicating whether the page can be read/modified).
An operation involving a memory access (e.g., reading data from a virtual memory address to a register) first determines an address translation by looking up in the page table. To accelerate this address translation, there is provided a cache called TLB (Translation Lookahead Buffer) including frequently used translations (i.e., mappings from virtual addresses to physical addresses). The TLB is a physical on-chip hardware that can be accessed in a few CPU cycles.
Because TLBs have a limited size, an OS or a CPU must be prepared to handle TLB misses (i.e., there is no entry in a TLB corresponding to a virtual address, so a mapping between the virtual address and a physical address is not found in the TLB). TLB may be a hierarchically structured cache (i.e., including a first level cache, a second level cache, a third level cache) as illustrated in FIG. 2. Lower level caches (e.g., TLB-i (110) in FIG. 2(a) or TLB-i (210) in FIG. 2(b)) is not visible to the OS or the CPU. Therefore, the TLB including multi level caches can be considered as a single cache memory.
There are two fundamental methods to manage a TLB: (a) hardware managed TLB (b) software managed TLB. In the hardware managed TLB, an entry is brought from a page table upon a TLB miss without an involvement of software (e.g., an OS). If an entry including an address translation is not found in a TLB and a page table which resides in a main memory, a page fault (i.e., an interrupt or exception caused by a fact that a page is not found in a main memory) is issued and an OS is invoked to resolve the page fault. The OS may retrieve the faulted page from a disk.
FIG. 2(a) illustrates an example of a hardware managed TLB (i.e., a TLB in which a TLB miss is handled by hardware (e.g., CPU or microcontroller)) A hardware managed TLB 104 may comprise multiple cache memories such as TLB-i (110) and TLB-0 (106). The TLB-i (110) is a lowest level cache in the hardware managed TLB 104. The TLB-0 (106) is a highest level cache in the hardware managed TLB 104. An application provides a virtual address 100 to the hardware managed TLB 104. If an entry corresponding to the virtual address 100 is found in the TLB-0 (106), a physical address 102 in the entry is provided to the application. If the entry is not found in TLB-0 (106), the hardware managed TLB looks up lower level caches (e.g., TLB-i (110)). If the entry is found in a lower level cache, the entry is provided to the TLB-0 (106) via a communication bus (108). Then, the entry is provided to the application.
If the entry is not found any cache in the hardware managed TLB 104, a CPU looks up a page table 114 in a main memory to find the entry. If the entry is found in the page table 114, the entry is provided to the hardware managed TLB 104 via a communication bus 112 and then provided to the application. In the hardware managed TLB 104, searching lower level caches (e.g., TLB-i (110)), searching a page table 114 and delivering the found entry to TLB-0 (106) are controlled by hardware (e.g., CPU or a microcontroller).
If the entry is not found in the hardware managed TLB 104 and the page table 114, the CPU raises a page fault and the OS looks up a disk 118 to find a page corresponding to the virtual address 100. Then, the OS provides the found page to a main memory and the page table 114 is updated to include the entry corresponding to the virtual address 100. Then, the found page is provided to the application. If the OS cannot find a page corresponding to the virtual address 100, the OS sends an error message to the application indicating the application provided a non-existing virtual address. In the hardware managed TLB, searching a disk and delivering the found page is controlled by software (e.g., the OS).
In a software managed TLB (i.e., a TLB in which a TLB miss is handled by software (e.g., an OS) after receiving a TLB miss exception (i.e., an exception indicating a TLB miss occurred) at the software (e.g., the OS)), a TLB miss causes an exception or an interrupt to the OS. The OS searches a page table to find a corresponding entry. Then, the OS updates the TLB with the found corresponding entry. If the corresponding entry cannot be found in the page table, the OS raises a page fault and handles the page fault (e.g., by searching a corresponding page in a disk).
FIG. 2(b) illustrates an example of a software managed TLB. In this example, an application issues an operation (e.g., reading a memory) including a virtual address 200. The virtual address 200 is provided to the software managed TLB 204. If an entry corresponding to the virtual address 200 is found in a highest level cache (e.g., TLB-0 (206), a corresponding physical address 202 in the entry is provided to the application.
If the entry is not found in highest level cache, an OS (an OS managing the application) looks up lower level caches (e.g., TLB-i (210)) to find the entry. If the entry is found in a lower level cache, the entry is provided to the highest level cache (e.g., TLB-0 206) via a communication bus 208. In the software managed TLB 204, exchanging data (e.g., the virtual address 204 and/or the entry) between caches in the software managed TLB 204 is managed by a hardware unit (e.g., a CPU or microcontroller).
If the entry is not found in the software managed TLB 204, the OS (the OS managing the application) looks up a page table 214 to find the entry in the page table 214. If the entry is found in the page table 214, the found entry is provided to the software managed TLB 204 and to the application. If the entry is not found in the page table 214, the OS raises a page fault and looks up a disk 216 to find a page corresponding to the virtual address 200. If the OS finds the page in the disk 218, the OS delivers the page to a main memory and updates the page table 214 to include the entry corresponding to the page. Then, the OS delivers the page to the application. In the software managed TLB 204, exchanging data (e.g., sending a found entry from the page table 214 to the software managed TLB 204) between the software managed TLB 204 and the page table 214 is controlled by software (e.g., the OS). Exchanging data (e.g., sending the virtual address 200 from the page table 214 to the disk 218) between the main memory where the page table 214 resides and the disk 218 is controlled by software (e.g., the OS).
Virtualized environments mean that one or more operating systems (guest OSs) are virtualized (i.e., virtually run) on top of hardware resource, requiring two levels of address translations. A software entity controlling the hardware resource and presenting an impression of a virtual machine to each of the guest operating systems is commonly referred to as a virtual machine monitor (VMM) or hypervisor (HV). To provide complete isolated address space between virtual machines, the guest operation systems managing the virtual machines cannot directly access a host page table (i.e., a page table managed by a hypervisor) or a TLB to read an address translation or to create an entry for a new address translation. To compromise this obstacle (e.g., no direct access to a host page table or a TLB), two level of translations are typically performed by first translating a guest virtual address (GVA; a virtual address used in a guest operating system; virtual address refers to an address used by an application to read or modify contents of virtual memory) to a guest physical address (GPA; a physical address used in the guest operating system) and then translating a host virtual address (HVA; a virtual address used in a hypervisor) to a host physical address (HPA; a physical address used in the hypervisor), where the GPA is equal to HVA as illustrated FIG. 3.
FIG. 3 illustrates an example of an address translation in a virtualized environment. In one example embodiment of a virtualized environment, depicted in FIG. 3, there are four address spaces per an application: a guest virtual address space 300 (i.e., an address space including guest virtual addresses), a guest physical address space 302 (i.e., an address space including guest physical addresses), a host virtual address space 304 (i.e., an address space including host virtual addresses) and a host physical address space 306 (i.e., an address space including host physical addresses). As shown in FIG. 3, a GVA 0x00010000 is mapped to (corresponds to) a GPA 310. A GPA 312 is mapped to (corresponds to) a HPA 318. A GPA 314 is mapped to (corresponds to) a HPA 316. A HVA 324 is mapped to (corresponds to) a HPA 320. A HVA 326 is mapped to (corresponds to) a HPA 322.
There may be a guest page table (i.e., a page table managed by a guest OS) storing mapping between GVAs and GPAs. There may a host page table (i.e., a page table managed by a hypervisor) storing mapping between HVAs and HPAs.
Neiger et al. (U.S. Pat. No. 6,907,600; hereinafter “Neiger”) discusses “creating a guest translation data structure to be used by a guest operating system for address translation operations, creating an active translation data structure based on the guest translation data structure, and periodically modifying the content of the active translation data structure to conform to the content of the guest translations data structure”. Neiger further discusses “the content of the active translation data structure is used by a processor to cache address translation in a translation-lookaside buffer (TLB)”.
However, Neiger and any existing prior art do not discuss allowing a guest operating system (guest OS; an operating system that is installed in a virtual machine in addition to a host or main operating system) to modify an entry in a TLB directly without an involvement of a hypervisor (i.e., a platform allows multiple operating systems to run on a computer at same time).
Thus, it would be desirable to provide a method and system for allowing a guest OS to modify an entry in a TLB directly without an involvement of a hypervisor.